Software systems exist that provide various services for enterprises or other organizations. Such software systems may rely on decentralized, manual, and potentially error-prone data collection, while storing collected data in a centralized back-end system where business logic execution also occurs. These and other software systems may be extended through the use of smart item (also referred to as smart device), technologies, in which physical items (e.g., goods, tools, rooms, vehicles, persons, or shelves) are augmented or enhanced by the addition or inclusion of locally-provided or embedded technology.
For example, radio-frequency identification (RFID) systems, embedded systems, sensor motes, and/or sensor networks may be used in the above-described manner to provide business software applications with fast access to real-world data. For example, smart item technologies may be used support the detection, reading, or writing of RFID tags, as well as to support communication with, and control of, wireless sensor networks and embedded systems. In many instances, smart items may include, or may be associated with, devices having local processing power, memory, and/or communication capabilities, and that are capable of providing data about the device and its properties, or information about a current state or environment of the smart item devices. Accordingly, some such devices may be used in the execution of service components of back-end or underlying business applications, and, in particular, may do so in a collaborative way, e.g., by forming mobile ad-hoc networks to collect, process, or transmit business data.
Examples of smart items may include an RFID tag, which may be passive or active, and which may be attached to a physical object, as referenced above, and used to provide product or handling information related to the object. Other examples of smart items may include various sensors, such as, for example, environmental sensors (e.g., a temperature, humidity, or vibration sensor), which, as just referenced, may be capable of communicating to form one or more sensor networks. These and other types of smart items also may include embedded systems, which may refer generally to any system in which a special-purpose processor and/or program is included, and/or in which the system is encapsulated in the device being controlled.
Through automatic real-time object tracking and local, on-site execution of application logic (e.g., business logic), smart item technology may provide accurate and timely data, and may help streamline and automate related operations. Accordingly, cost reductions and additional business benefits (e.g., increased asset visibility, improved responsiveness, and extended business opportunities) may be obtained.
In practice, smart item and related technologies may be susceptible to a number of different types of flaws or faults, which may impair, alter, or prevent a desired behavior(s). Such faults may be related, for example, to a malfunction in an operation of the individual nodes themselves, such as when a node experiences a hardware or software failure. Faults also may relate to external forces, such as a fire or flood, which may affect the nodes. Faults also may occur at a network layer, e.g., during routing of messages between nodes. As a final example, faults may occur that are related to back-end applications attempting to benefit from the network(s) of nodes, such as when a back-end application(s) requests data from the network(s) of nodes in an incorrect manner.
Such faults may be problematic for a number of reasons. For example, failure to obtain necessary data from a node may cause a malfunction of another node, or of the back-end application(s). Even if the fault does not prevent local operations of a given node, then problems may arise if incorrect data is reported to the back-end application(s). Further, it may be difficult to determine where a potential fault may have occurred within the networks of nodes and associated data collection/processing devices. Consequently, failure to detect, determine, and correct such faults may result in otherwise-unnecessary costs, liabilities, or other difficulties.
Further with regard to such faults, and as referenced above, it may be appreciated that nodes may communicate with one another to form local networks, e.g., sensor networks. In a given sensor network, such communication may occur using a proprietary communications protocol that is understood by each of the network nodes, but that may not be understood by other nodes and/or networks. For example, the communications protocol of a sensor network may be unique to a particular hardware and/or software platform used in the sensor network, or may be unique to a manufacturer of the nodes. Accordingly, it may be difficult to collect (and respond to) fault-related data regarding such sensor networks in a timely fashion, in a format that is applicable to multiple ones of the sensor networks, and without overwhelming or depleting communications resources of the devices and/or sensor networks.